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(57) Abstract 

A client/server computer system for remote editing 
of document objects stored on the server includes a client 
computer connected to a server computer via a communication 
channel over which messages arc sent in a communication 
protocol. Typically, the client computer has an operating 
system with the first file name space and the server computer 
has an operating system with a second file name space and the 
first file name space docs not include names of files which map 
to names of files in the second file name space. The connection 
is preferably a TCP/IP connection providing data transport 
according to TCP/IP. Messages in the HTTP protocol arc 
preferably used. The client computer sends request messages 
to the server. A request message may indicate a request for 
eifter retrieval or storage of a document object, such as an 
HTML document or script program. The server receives the 
request messages and processes them to eitiwr store a document 
object or retrieve a docximent object and return it to th e client 
in a response message. When the server is an HTTP server, 
the request messages from the client arc processed by a single 
control script. The messages from the client indicate a desired 
document object and the action to be performed. 
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MOTE 



AND 

FPf T^Nr. OF C OM?VT^^^^ P^^ES 

Field of tbp invention 

This invention is related to computer editing systems for editing electronic documents, 
other mformation and computer programs. More particularly, this invention is related to 
computer editing systems for developing on-Une services m a client-server information system. 

Rack proun ^ »f ^hi* Invention 

An on-line information system typically includes one computer system (the server) that 
makes information available so that other computer systems (the clients) can access the 
information. The serN-er manages access to the information, which can be structured as a set of 
independem on-line services. The server and diem communicate N-ia messages conforming to a 
communication protocol and sent over a communication channel such as a computer network or 

through a dial-up connection. 

Tvpical uses for on-line ser^'ices include document viewing, electronic commerce, 
director)' lookup, on-line classified advertisements, reference services, electronic bulletin boards, 
document retrieval, electronic publishing, technical support for products, and directories of on- 
line services, among others. The service may make the information available free of charge, or 
for a fee. 

Information sources managed by the scr%'er may include files, databases and applications 
on the ser^•cr system or on an external system. The information that the server provides simply 
may be stored on the server, may be converted from other formats manually or automatically, 
may be computed on the server in response to a client request, may be derived from data and 
i applications on the server or other machines, or may be derived by any combination of these 
techniques. 

The user of an on-line service uses a program running on the client system to access the 
information managed by the on-line serx'ice. Possible user capabilities include viewing, 
searching, downloading, printing, and filing the information managed by the ser^-er. The user 
0 may also price, purchase, rent, or reserve services or goods offered through the on-line ser%'ice. 

For example, an on-line service for catalog shopping might work as follows. The user 
runs a program on the client system and requests a comiection to the catalog shopping ser^'ice 
usina a service name that either is well known or can be found in a directory. The request is 
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received by the serN'er. and the ser%'er returns an introductory page that also asks for an identifier 
and passNvord. The client program displays this page, the user fills in an identifier and password 
that were assigned by the service in a previous visit, and the user's information is sent to the 
server. The ser^'er verifies the identifier and password against an authorization database, and 
returns a menu page that is then presented to the user. Each time the user selects a menu item, 
the selection is sent to the server and the server responds with the appropriate new page of 
information, possibly including item descriptions or prices that are retrieved from a catalog 
database. By selecting a series of menu items the user navigates to the desired item in the 
catalog, and requests that the item be ordered. The server receives the order request, and returns 
a form where the user fills in some information about shipping and billing. The user response is 
returned to the server, and the server enters the order information into an order database. 

On-line services are available on the World Wide Web (WWW), operating ovzr the 
Global Internet in which a large number of computers, or sites, are interconnected. The WWW is 
a "web" of interconnected document objects that are located on various sites on the Internet. The 
WWW is also described in "The World-Wide Web." by T. Bemers-Lee. R. Cailliau. A. 
Luotonen. H. F. Nielsen, and A. Secret, ronimnnirntions of the ACM, 37 (8). pp. 76-82. August 
1994. and in "World Wide Web: The Information Universe." by Bemers-Lee. T.. ei al.. in 
P...t.nni. Networklnr- P -nr^ Arp.;..>inn.nnd Policy. Vol. I. No. 2. Meckler. Westport. 
Conn.. Spring 1992. Among the types of document objects on the WWW are documents and 
scripts. Documents that are published on the WWW are written m the Hypertext Markup 
Language ( HTML), such as described in Hvpenext Markup I ■^r^v^^m S pecification - 2.0 . by T. 
Bemers-Lee and D. Connolly. Internet Draft Document. October 14. 1994. and in "World Wide^ 
Web & HTML." by Douglas C. McArthur. in Pr Dobbs Journal, December 1994. pp. 18-20. 22. 
24. 26 and 86. HTML documents stored as such are generally static, that is. the contents do not 
; change over time unless the ser^.ice developer modifies the document. Scripts are programs that 
can generate HTML documents when executed. 

HTML is a language used for writing hypertext documents. The formal definition is that 
HTML documents are Standard Generalized Markup Language (SGML) documents that conform 
to a particular Document Type Definition (DTD). An HTML document includes a hierarchical 
0 set of markup elements, where most elements have a start tag. followed by content, followed by 
an end tag. The content is a combination of text and nested markup elements. Tags are enclosed 
in angle brackets (•<• and '>*) and indicate how the document is stnictured and how to display 
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the document, as well as destinations and labels for hypertext links. There are tags for markup 
elements such as titles, headers, text attributes such as bold and italic, lists, paragraph 
boundaries, links to other documents or other parts of the same document, in-line graphic 
images, and many other features. 

For example, here are several lines of HTML: 

Some words are <B>bold</B>. others are <l>italic</l>. Here we start a new 
paragraph.<P> Here's a link to 

the <A HREF="http://wv^v.vemieer.com">Vermeer Technologies. Inc.</A> home page. 



10 



This sample documem is a hypertext documem because it contains a "link" to another 
documem. as provided by the ••HREF=." The format of this Imk will be described below. A 
hypertext document may also have a link to other parts of the same document. Linked 
documents may generally be located anywhere on the Internet. When a user is viewing the 
1 5 documem using a Web browser (described below), the links are displayed as highlighted words 
or phrases. For example, usmg a Web browser, the sample documem above would be displayed 
on the user's screen as follows: 

Some words are bold, others are italic. Here we start a new paragraph. 
20 Here's a link to Vermeer Te chnologies. Inc. home page. 

In the Web browser, a link may be selected, for example by clicking on the highlighted 
area with a mouse. Selecting a link will cause the associated document to be displayed. Thus, 
clicking on the highlighted text "Vermeer Technologies. Inc." would display that home page. 

25 Another kind of documem object on the WWW is a script. A script is an executable 

program, or a set of commands stored in a file, that can be run by a Web server (described below) 
to produce an HTML document that is then returned to the Web browser. Typical script actions 
include library routines or other applications to get information from a file or a database, or 
initiating a request to get information from another machine, or retrieving a document 

30 corresponding to a selected hypertext link. A script is run on the Web server when, for example, 
the end user selects a particular hypertext link in the Web browser, or submits an HTML form 
request. Scripts are usually written by a service developer in an interpreted language such as 
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Basic or Tool Control Language (Tel) or one of the Unix operating system shell languages, but 
they also may be written in programming languages such as the "C" programming language and 
then compiled into an executable program. Programming in Tel is described in more detail in 
TH nnH the Tk Toolkit by John K. Ousterhout. Addison-Wesley. Reading, MA. USA. 1994. 

Each document object m the WWW has an identifier called a Uniform Resource 
Identifier (URI). These idemifiers are described in more detail in lipivprsf^l Resourre Idemiflgrs 
f^.th. Wr^rlHWide Web . T. Bemers-Lee. submitted as an Internet Request for Comments (RFC) 
as yet unnumbered. A URI allows any object on the Intemet to be referred to by name or 
address, such as in a link in an HTML document as shown above. There are two types of URls: 
a Universal Resource Name (URN) and a Unifom. Resource Locator (URL). A URN references 
an object by name within a given name space. The Intemet community has not yet defmed the 
syntax of URNs. A URL references an object by defining an access algorithm usmg network 
protocols. An e.xample URL is ••http://www.vermeer.com" A URL has the syntax 
••scheme://host:porvpath?search" where "scheme" identifies the access protocol (such as HTTP. 

FTP or GOPHER): 

"host" is the Intemet domain name of the machine that supports the protocol: 

-port" is the transfer control protocol (TCP) port number of the appropriate ser^'er (if different 

from the default): 

"path" is a scheme specific identification of the object; and 

■ search" contains optional parameters for querying the contem of the object. 

An Internet site that wishes to make documents available to network users is called a 
"Web site" and must run a "Web server ' program to provide access to the documents. A Web 
server program is a computer program that allows a computer on the network to make documents 
available to the rest of the WWW. The documents are often hypertext documents in the HTML 
language, but may be other types of documents as well, as well as images, audio and video 
information. The information that is managed by the Web serN-er includes hypertext documents 
that are stored on the server or are dynamically generated by scripts on the Web server. Several 
Web server software packages exist that provide information on the Web. such as the Conseil 
Europeen pour la Recherche Nucleaire (CERN. the European Laborator>' for Paa.cle Physics) 
0 server or the National Center for Supercomputing Applications (NCSA) ser^'er. Web servers 
have been implemented for several different platforms, including the Sun Sparc 11 workstation 
running the Unix operating system, and personal computers with the Intel Pentium processor 
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running the Microsoft MS-DOS operating system and the Microsoft Windows operating 
environment. The Web server also has a standard interface for nmning external programs, called 
the Common Gateway Interface (CGI). A gateway is a program that handles incoming 
information requests and returns the appropriate document or generates a document dynamically. 
For example, a gateway might receive queries, look up the answer in an SQL database, and 
translate the response into a page of HTML so that the server can send the result to the client. A 
gateway program may be written in a language such as "C" or in a scripting language such as 
Practical Extraction and Report Language (Peri) or Tel or one of the Unix operating system shell 
languages. Perl is described in more detail in PropFfimming Pgrl. by Larry Wall and Randal L. 
Schwartz. O'Reilly & Associates. Inc.. Sebastop&l. CA, USA. 1992. The CGI standard specifies 
how the script or application receives input and parameters, and specifies how any output should 
be formatted and returned to the server. 

Generally speaking, for security reasons, a Web server machine may limit access to files. 
For all access to files on the Web server, the Web server program rumiing on the ser%'er machine 
may provide an extra layer of security above and beyond the normal file system and login 
security procedures of the operating system on the server machine. The Web server program 
may add further security rules such as: 1 ) optionally requiring user name and password, 
completely independent of the normal user name and passwords that the operating system may 
have on user accounts. 2) allowing definitions of groups of users for security purposes, 
independent of any user group definitions of the operating system. 3) access control for each 
document object such that only specified users (with optional passwords) or groups of users are 
allowed access to the object, or that access is only allowed for clients at specific network 
addresses, or some combination of these rules. 4) allowing access to the document objects only 
through a specified subset of the possible HTTP methods. 5) allowing some documem objects to 
5 be marked as HTML documents, others to be marked as executable scripts that will generate 
HTML documents, and others to be marked as other types of objects such as images. Access to 
the online service document objects via a network file system would not conform to the security 
features of the Web server program and would provide a way to access documents outside of the 
security provided by the Web server. The Web server program also typically maps documem 
0 object names that are known to the client to file names on the server file system. This mapping 
may be arbitrarily complex, and any author or program that tried to access documents on the 
Web server directly would need to understand this name mapping. 
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A user (typically using a machine other than the machine used by the Web ser%'er) that 
wishes to access documents available on the network at a Web site must run a client program 
called a "Web browser." The browser program allows the user to retrieve and display documents 
from Web servers. Some of the popular Web browser programs are: the Navigator browser from 
NetScape Communications. Corp.. of Mountain View, California; the Mosaic browser from the 
National Center for Supercomputinc Applications (NCSA): the Win Web browser, from 
Microelectronics and Computer Technology Corp. of Austin. Texas; and the Internetworks 
browser, from BookLink Technology, of Needham. Mass. Browsers exist for many platforms, 
including personal computers with the Intel Pentium processor runnmg the Microsoft MS-DOS 
operating system and the Microsoft Windows environment, and Apple Macintosh personal 
computers. 

The Web server and the Web browser communicate using the Hypertext Transfer 
Protocol (HTTP) message protocol and the underlying TCP/IP data transport protocol of the 
Internet. HTTP is described in Hyr^Tt^vt Transfer Proincol - HTTP/1,0. by T. Bemers-Lee. R. 
T. Fielding, H. Fry sty k Nielsen. Internet Draft Document. December 19. 1994. and is currently in 
the standardization process. In HTTP, the Web browser establishes a connection to a Web ser^'er 
and sends an HTTP request message to the server. In response to an HTTP request message, the 
Web ser^'er checks for authorization, performs any requested action and returns an HTTP request 
message containing an HTML document resulting from the requesied action, or an error 
message. The returned HTML document may simply be a static file stored on the Web server, or 
it may be created dynamically using a script called in response to the HTTP request message. 
For instance, to retrieve a static document, a Web browser sends an HTTP request message to the 
indicated Web serx-er. requesting a document by its URL. The Web server then retrieves the 
document and returns it in an HTTP response message to the Web browser. If the document has 
i hypertext links, then the user may again select a link to request that a new document be retrieved 
and displayed. As another example, a user may fill in a form requesting a database search, the 
Web browser will send an HTTP request message to the Web server including the name of the 
database to be searched and the search parameters and the URL of the search script. The Web 
server calls a program or script, passing in the search parameters. The program examines the 
0 parameters and attempts to answer the query, perhaps by sending a query to a database interface. 
When the program receives the results of the quer>', it constructs an HTML document that is 
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retumed to the Web server, which then sends it to the Web browser in an HTTP response 
message. 

Request messages in HTTP contain a "method name" indicating the type of action to be 
performed by the server, a URL indicating a target object (either document or script) on the Web 
server, and other control information. Response messages contain a status line, server 
information, and possible data content. The Multipurpose Internet Mail Extensions (MIME) are 
a standardized way for describing the content of messages that are passed over a network. HTTP 
request and response messages use MIME header lines to indicate the format of the message. 
MIME is described in more detail in MIMF. rMultimimose Internet Mail F,x^gn§iQn?); 
Mfchani5;m5; for s;ppr,ifving and n^^rrihin ? the Format of Internet Message Bod i gS , Internet RFC 
1341. June 1992. 

The request methods defined in the current version of the HTTP protocol include GET. 
HEAD. POST. PUT. DELETE. LINK, and UNLINK. The GET method requests that the server 
retrieve the object indicated by the given URL and send it back to the client. If the URL refers to 
a document, then the server responds by sending back the document. If the URL refers to an 
executable script, then the server executes the script and returns the data produced by the 
execution of the script. Web browser programs normally use the GET method to send request 
messages to the Web server to retrieve HTML documents, which the Web browser then displays 
on the screen at the client computer. 

According to the HTTP specification, the PUT method specifies that the object contained 
in the request should be stored on the server at the location indicated by the given URL. 
However, the current server implementations do not follow this specification: they simply handle 
all PUT requests through a single PUT script, which is generally undefined, and must be created 
by a service author. Web browsers generally do not use the PUT method. 

The POST method sends data, usually the user input parameters from an HTML form, to 
the server. The POST request also contains the URL of a script to be run on the server. The 
server runs the script, passing the parameters given in the request, and the script generates 
HTML output to be returned in the response to the client. In order for a client program to send 
arbitrary data to the Web server using the current HTTP protocol, the client program must use 
either the PUT method or the POST method, as these are the only two methods that allow such 
data transfer to the Web server. 
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Having now described the World Wide Web. a typical on-line service on the WWW will 
now be described. An on-line service on the Worid Wide Web includes a Web server program 
running on a Web ser%'er machine, and a set of service files that characterize the on-line services 
that are stored on the Web sen-er machine. The service files include HTML documents, 
executable scripts or programs to dynamically produce HTML documents, and other files of 
service information that can be referenced and updated by the scripts and programs. The actual 
data and scripts that make up a particular on-line service, including HTML documents and scnpi 
programs, are generally stored on the server in a separate area for each service. Global 
information about the service is also stored, including data such as the name of the service, the 
name of the author, revision histor>'. comments about the service, and authorization information. 
The end user of the on-line service uses a Web browser program on the client machine to send 
requests to the on-line service and to receive responses from the on-line service. All access by an 
end user of the on-line service to the service files is managed and controlled by the Web ser%'er 
program. For example, an on-line .service might consist of a corporate home page which is a 
static documem. with a link to a second document that is a form for searching the store catalog. 
The search form may have a "submit" button that causes a script to be run on the Web server, to 
generate a list of product descriptions with prices that is then returned to the Web browser as an 
HTML document. Each of the HTML documents may have a link to a second script that collects 
and displays the items that have been ordered. The service also has configuration information 
) such as the list of authorized users of the service, and their passwords. 

Figure 1 shows the steps in using an on-line service, as seen by the end user of the on-line 
service on the client machine. The end user starts a Web browser program in step 10. and the 
program determines the URL of an initial document to display in step 12. The initial document 
URL may be determined from a configuration file, or may be programmed into the Web browser. 
5 or may be entered by the user. The browser then sends an HTTP GET request to the Web server 
in step 14. giving the URL of the desired document. The browser then waits for a response from 
the Web server in step 16. The browser tests the response in step 18 to determine if it indicates 
an error message. If the response message from the Web server indicates an error, for instance if 
the requested document is not found, then the browser reports the error to the end user in step 22. 
50 Otherwise the response message from the Web server contains the requested document, and the 
Web browser formats and displays the document on the screen in step 20 according to the HTML 
language conventions. In either case the browser then wails for the user to enter the next 
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command (step 24). For example, the user may request to view a new document by selecting a 
hypertext link to a document, by requesting a document from a list of previously visited 
documents, or by typing in the URL of a document that was obtained by the user through some 
other means. The browser tests the user command to determine if the user is requesting a new 
document in step 26. If so. processing continues at step 14 which has already been discussed. If 
the user is not requesting a new document then the browser tests the command in step 30 to 
determine if h is a request to exit the program. If so, processing stops. Otherwise the command 
is a local command that is handled by the browser without sending an HTTP request in step 28. 
The end user may use local viewing commands such as commands to scroll around in the 
document, or commands to search for a particular text string in the documem. After the browser 
handles the local command, the browser again waits for the next user command as already 
discussed, in step 24. 

Figure 2 shows the operation of an on-line service on the World Wide Web as seen by the 
Web server program. When the server is started, it runs continuously, waiting to receive a 
command over the network connection from a client Web browser program in step 40. The 
server tests the received command in step 44 to determine if it is a GET request. If it is a GET 
request, then the server examines the URL contained in the request in step 52 to determine if the 
URL indicates a static HTML document stored on the server. If the URL does refer to a static 
document then that document is returned to the Web browser via an HTTP response in step 58. 
Otherwise the URL indicates a script stored on the server, and the Web server runs the script to 
produce an HTML document in 56 which is then returned to the Web browser as described 
before in step 58. If the test of step 44 determines that the command is not a GET request, then 
the server tests the command in step 48 to determine if it is a POST request. If so. the server 
retrieves the parameters from the POST request in step 54, which include the URL for the script 
and the parameters for the script. The server then runs the indicated script in step 56 to generate 
an HTML document which is then returned to the Web browser as described before in step 58. 
After an HTML document is returned to the Web browser, processing continues at step 40. If the 
test of step 48 determines that the command is not a POST request then the server returns an 
error message to the Web browser in step 50. formatted as an HTML document. The processing 
continues at step 40 and the server again waits for the next request and the process repeats. 

On-line services such as those described above are in high demand. Unfortunately, the 
task of developing an on-line service is currently one that almost always requires extensive 
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programming skill and much specialized knowledge. There exists a great need for tools that will 
simpliiy the process of building an on-line seivice so that the process will take less lime, be less 
eaor prone, and can be done by a nonprogrammer. In some cases, software tools exist to help 
convert the content data for the service from its native format to the fonnat required by the 
5 server, but these tools only address the conversion of static data files. 

For example, in order to construct an on-line service for the World Wide Web. the service 
author performs a combination of the tasks, such as creatmg a new HTML document for a page 
of hypertext included in the on-line service, creating a new script included in the on-line service, 
retrievme and modifying an existing HTML document from the Web server machine, retrieving 
,0 and modifying an existing script from the Web server machine, and storing an HTML document 
or script on the Web server machine so that the Web server program will have access to it. 

There are several approaches known m the prior art for constructmg documents and 
scripts of an on-line service on the Web. and performing the tasks noted above. The first 
approach is that the service author runs a text or HTML editor program on the Web server 
15 machine to create or modify the on-line service documents and scripts that are stored on the 
server. 

The problem with the first approach is that the service author must be working at the Web 
server machine, or at least working at a terminal which is directly comiected with the server 
machine. This is not always practical, because the service author may be at a location which is 

20 physically remote from the server machine. It also often happens that the server machine 

requires a high level of security because of the nature of the resources on the server machine that 
may be shared among a number of users. In this case access to the machine is often limited to 
the system administrators, and the service author may not have access to the machine for securit>' 
reasons. For example, the only access to files used by the Web server may be through the Web 

25 server alone. 

The second approach is that the service author may run a terminal emulation program on 
a client machine to establish a connection to the server machine over a network comiection or a 
modem line. The terminal emulation program allows the user to run programs on the server 
machine as though the user were working directly on that machine, and with this arrangement the 
30 user runs a text or HTML editor program on the server to create or modify the on-line service 
documents and scripts as before. 
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The second approach has the problem that the server machine and client machine must 
both run additional programs to allow terminal emulation and remote execution of programs over 
a network. This adds to the complexity on both machines, and also requires that the service 
author be familiar with a terminal emulation program which typically has a difficult user 
interface that is not meant for nonexperts. This approach also adds another route from other 
machines to the server machine, which may be undesirable for security reasons. As with the first 
approach, the service author may not have access to the server machine for security reasons, or 
may not have authorization to write files to the machine. 

In the third approach, the service author first transfers existing service documents and 
scripts from the server machine to a client machine either manually or via a network file transfer 
program. The author then runs a text or HTML editor program on a client machine to create or 
modify documents on that machine, and then transfers the completed documents back to the 
server machine either manually or via a network file transfer program, such as the file transfer 
protocol (ftp) or kermii. a file transfer method used with terminal emulation programs for 
communication over a modem. 

The third approach is cumbersome because of the need for the separate steps of 
transferring the documents from the server back to the client, and transferring the documents 
back to the server after the editing is complete. This approach also has the security problems 
mentioned above for the other approaches. 

Each of these three approaches also has the problem that the file names used for 
documents by a Web server are not always the same as the actual file names of the documents. 
An author of an on-line service will need to leam the mappings of file names to the URLs used 
by the Web server. 

There is also the World Wide Web computer program, for use with a NeXT computer, 
that consists of a client browser program that is able to retrieve files from a Web server, and a 
client HTML editor that can edit the retrieved file. However, this program is not able to save the 
edited files to the Web server. Instead, this approach is similar to the third approach discussed 
above in that a file transfer program is still needed to place the edited document back on the Web 
server. This approach also is not a complete solution for authoring an on-line service for the 
Web because the types of documents edited in this manner are limited to static HTML 
documents which are not processed in any way by the server. 
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Summar y of the Invention 

To overcome the drawbacks of current methods for creating an on-line service on the 
World Wide Web. one embodiment of this invention provides a client authoring tool that can 
both retrieve and store document objects on a Web server using a communication protocol in 
which messages are sent over a TCP/IP connection between the server and the cliem. In one 
embodiment, the communication protocol is HTTP, the same communication protocol used by 
Web browsers. The architecture of this system is applicable to other communication protocols 
and client/server on-line services. 

One of the difficulties in implementing a client program to save files to a Web server 
using HTTP is that, ahhough existing Web servers, such as the CEKN server and the NCSA 
server, have support for the HTTP PUT and POST methods, these existing servers still require 
development and installation of a script on the server to handle either PUT or POST methods. 

Another difficulty in implementing a method for remote authoring and editing of an on- 
line service over the HTTP protocol is lhat there are two types of component objects for the on- 
5 line service that are stored on the Web server. These are static HTML documems. and scripts 
that dynamically generate HTML documents upon request. If an authoring program would like 
to retrieve a script from the ser^'er. using the HTTP protocol, it cannot simply use the HTTP GET 
method that is normally used to retrieve documents and access scripts during the operation of an 
on-line service. The reason is lhat the HTTP GET method, when used to access a script, causes 
0 the script to be executed and returns an HTML document that is generated through execution of 
the script. 

Another difficulty in editing documents for an on-line service in this environment is thai 
a client authoring program generally does not have a file name space that includes the file names 
of the document objects of the on-line service on the server. Such an overlap in the file name 
:5 space generally requires use of a network file system. Creation of a network file system 

including the authors of all on-line services on a server is generally impractical. Such a system is 
also generally too complex to set up easily and requires too much close interaction among 
systems than is practical on a large heterogenous public network like the Internet. In many cases, 
a client authoring system would not have access to the ser\'er anyway to enable the set up of a 

30 network file system. 

To generally overcome these difficulties, one aspect of the invention is a computer- 
implemented process for remotely editing an electronic document stored on a server computer. 
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using a client computer, wherein the server computer and tiie client computer are connected by a 
communication channel and send messages using a communication protocol. In this process, the 
client computer sends a request message using the communication protocol over the 
communication channel to the server requesting a copy of the electronic document. Next, the 
client receives a response message in the communication protocol from the server and over the 
communication channel, wherein the response message contains the copy of the electronic 
document. The client then permits a user to edit the copy of the electronic document at the client 
computer. To store the electronic document at the server, the client sends a message in the 
communication protocol including the edited electronic document over the commimication 
channel and to the ser\'er. wherein the message includes an indication of a request that the 
electronic document be stored on the server computer at a particular location. Typically, the 
server sends a status response message indicating the outcome of the attempt to store the 
document. 

In one embodiment, to overcome these difficulties, the authoring tool uses either PUT or 
POST HTTP request messages to request retrieval of scripts or documents and to request storage 
of edited or new documents or scripts. Currently available authoring tools may be readily 
modified to replace existing "open" and "save" functions to provide this capability. The server 
may be any standard Web server program such as the CERN server or the NCSA ser\'er. Our 
invention provides a control script which is executed by the server for each incoming PUT or 
POST HTTP request messages lo determine whether a document is to be reu-ieved or replaced. 
The authoring tool program uses the HTTP protocol to communicate with a server program 
running on the server machine. The communication takes the form of the authoring tool sending 
a request to the ser\'er program, the server program executing a control script to perform the 
indicated action and write the results to an output file, and the server sending a response message 
back to the authoring client with the output. The output may be either a status message 
indicating that the action was performed successfully, or contents of a document or script that 
was retrieved, or an error message indicating why the action could not be performed. The server 
program may still communicate with browsers at the same time the authoring tool is being used. 
The server continually listens to incoming messages. If an incoming PUT or POST HTTP 
request is not from the authoring tool, it is handled in the same manner as other PUT or POST 
request messages from other client programs such as Web browsers. Otherwise, the server 
passes the request parameters to the control script. The control script checks the parameters to 
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ensure that the request is valid, and checks that the user of the authoring tool has the proper 
authorization. The control script then carries out the request, retrieving or creating, or modifying 
files of the appropriate on-line service as required. 

Another aspect of the invention, in one embodiment, is a computer-implemented process 
for a client to remotely edit a documem object stored on a server, wherein the client and the 
server send messages using the HTTP protocol over a TCP/IP connection. In this process, the 
client establishes a TCP/IP connection with the server. Then, the diem sends an HTTP request 
message over the TCP/IP comiection to the server, wherein the HTTP request message specifies 
the document object and an indication that the client requests retrieval of the document object. 
The server receives the HTTP request message and calls a control script. The control script 
checks authentication and retrieves a copy of the document object if access is authemicated. The 
server sends the copy of the document object to the client over the TCP/IP comiection in an 
HTTP response message. The cliem receives the HTTP response message including the copy of 
the documem object. The TCP/IP connection is lemiinated and the client permits a user to edit 
the copy of the document object. To store the edited or new document on the server, the cliem 
establishes a TCP/IP comieciion with the server and sends an HTTP request message to the 
server, wherein the HTTP request message contains a copy of the edited document and an 
indication of a location on the server to store the copy of the edited document object and an 
indication that the cliem requests storage of the edited documem object. The server receives the 
HTTP request message and calls the control script. The control script stores the copy of the 
edited document object on the server at the location specified in the HTTP request message. The 
server sends an HTTP response message acknowledging an attempt at storage of the edited 
document object. Finally, the TCP/IP connection is terminated. 

Another aspect of the presem invention is a computer-implemented process for enabling a 
cliem computer to store a documem object on a server computer. In this process the serx'er 
receives an HTTP request message from the client computer over a TCP/IP comiection. wherein 
the HTTP request message has contem including a copy of the documem object and an indication 
of a location on the server computer to store the copy of the documem object and an indication 
that the cliem computer requests storage of the documem object. The server executes a process 
0 using the contem of the HTTP request message to store the copy of the document object on the 
server computer according to the indication of the location included in the HTTP request 
message. 
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Another aspect of the invention is a computer system for enabling a client computer to 
store a document object on a server computer. The server computer includes a mechanism which 
receives an HTTP request message from the client computer over a TCP/IP connection, wherein 
the HTTP request message has content including a copy of the document object and an indication 
of a location on the ser\'er computer to store the copy of the document object and an indication 
that the client computer requests storage of the document object. The server computer also 
includes a mechanism which executes a process using the content of the HTTP request message 
to store the copy of the document object on the server computer according to the indication of the 
location included in the HTTP request message. 

Another aspect of the invention is a server computer in a computer system for enabling a 
client computer to store a document object on the ser\'er computer. The ser\'er computer 
includes a computer-readable and writable storage medium and a TCP/IP mechanism, having an 
input for receiving a request from the client computer to establish a TCP/IP connection with the 
client computer and which establishes the TCP/IP connection. The server computer also 
includes an HTTP ser\'er having an input for receiving an HTTP request message from the client 
computer over the TCP/IP connection via the TCP/IP mechanism, wherein the HTTP request 
message has content including a copy of the document object and an indication of name used by 
the HTTP server to retrieve the document object as stored on the storage medium and an 
indication that the client computer requests storage of the document object, and an output for 
storing the copy of the document object from the HTTP request message on the computer- 
readable and writable storage medium as a file according to the name included in the HTTP 
request message. 

Another aspect of the invention is a computer-implemented process for enabling a client 
computer to store a document object on a server computer. In this process, the client computer 
establishes a TCP/IP connection with the server computer. Then, the client computer sends an 
HTTP request message to the ser\'er computer over the TCP/IP connection, wherein the HTTP 
request message has content including a copy of the document object and an indication of a 
location on the sen'er computer to store the copy of the document object and an indication that 
the client computer requests storage of the document object. The client computer then receives 
an HTTP response message from the server computer indicating a result of an attempt by the 
server computer to store the copy of the document object. 
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Another aspect of the invention is a compuier-implemented process for enabling a client 
computer to store a document object on a server computer. In this process, the server computer 
receives a request message from the client computer, wherein the request message has content 
including a copy of the document object, an indication of a location on the server computer. 
5 defining an indicated name which is a universal name used by other clients to access the 
document object on the server computer, and an indication that the document object is to be 
stored in the indicated location on the server computer. The server computer then converts the 
indicated name into a file name in a file name space of the server computer and storing the 
document object as a file on the ser\'er computer using the file name in the file name space of the 
10 server computer. The server computer then sends a response message to the client computer 
acknowledging storage of the document object. 

Another aspect of the invention is a computer system for enabling a client computer to 
store a document object on a server computer. The server computer includes a mechanism for 
receiving a request message from the client computer, wherein the request message has content 
15 including a copy of the document object, an indication of a location on the server computer, 
defining an indicated name which a universal name to be used by other clients to retrieve the 
document object, and an indication that the document object is to be stored in the indicated 
location on the server computer. The server computer also includes a mechanism for converting 
the indicated name into a file name in a file name space of the ser\'er computer and storing the 
20 document object as a file on the server computer using the file name in the file name space of the 
server computer. The ser\'er computer also includes a mechanism for sending a response 
message to the client computer acknowledging storage of the document object. 

Another aspect of the invention is a computer system for enabling a client computer to 
store a document object on a server computer. The server computer includes a computer-readable 
25 and writable storage medium and a server program executed on the server computer. The ser\'er 
program, as executed- has an input connected to receive a request message from the client 
computer, wherein the request message has content including a copy of the document object, an 
indication of a name to be used by the server program to retrieve the document object which is a 
universal name used by other clients to retrieve the document object, and an indication that the 
30 document object is to be stored on the computer-readable and writable storage medium. The 
server program as executed also has a first output for providing a file name in a file name space 
of the server computer converted from the indicated name in the received message and a 
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command to the server computer to store the document object as a file on the computer-readable 
and writable storage medium using the file name in the file name space of the server computer. 
The server program as executed also has a second output connected to the client computer to 
provide a response message to the client computer acknowledging storage of the document 
5 object. 

In the aspects of the invention where the server receives a universal name, the universal 
name may be a URL or equivalent indicator. Such a universal name is different from a file name 
used by, for example. FTP because in FTP a message contains actual file name on server and 
maintains current working directory information of the user who has logged into the server. 
10 Additionally, such a universal name is different from a file name such as used by a network file 
system (NFS). In NFS, a message contains physical file name and may maintain current working 
directory information. In NFS, the mapping of file names and directories is client-dependent and 
not client independent. In contrast, using HTTP or other server using universal, or client- 
independent names, a message uses a URL which contains a protocol ://host/path which is passed 
15 through a mapping step. Thus, a file is accessible on the server only if it is listed in a mapping 
table of the server which matches trees of directories to URLs. The URL by itself typically 
cannot be used without a server to identify the file, unlike file names used in FTP. HTTP also 
has further rules which allow multiple mappings of subdirectories, unlike file names in NFS. 
Different security may also be provided on different subdirectories using HTTP. In other words, 
20 using HTTP and URLs, a names using a directory x and names using subdirectory x/y may be 
mapped to different places on server. Additionally, permissions associated with a director^' x 
and subdirectory x/y may be different on the server. 

Another aspect of the invention is a computer-implemented process for enabling a client 
computer to store a document object on a server computer. In this process, a server computer 
25 receives a request message from the client computer, wherein the request message has content 
including a copy of the document object, an indication of an application sending the message, an 
indication of a location on the server computer, and an indication that the document object is to 
be stored in the location on the server computer. The server then determines whether the request 
message is from an authorized source by comparing the indication of the application in the 
30 content of the request message with accepted applications. When the request message is from an 
authorized source, the server stores the document object on the server computer using the 
location indicated in the request message and sending a response message to the client computer 
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acknowledging storage of the document object. When the request message is not from an 
authorized source, the server sends a response message to the client computer without storing 
the document object on the server computer. 

Another aspect of the invention is a computer system for enabling a client computer to 
store a document object on a server computer. The server computer includes a mechanism for 
receiving a request message from the client computer, wherein the request message has content 
including a copy of the document object, an indication of an application sending the message, an 
indication of a location on the server computer, and an indication that the document object is to 
be stored in the location on the server computer. Another mechanism determines whether the 
request message is from an authorized source by companng the indication of the application m 
the content of the request message with accepted applications. The server also includes a 
mechanism, operative when the request message is from an authorized source, for storing the 
document object on the serx'er computer using the location indicated in the request message and 
sending a response message to the client computer acknowledgmg storage of the document 
; object. Another mechanism is operative when the request message is not from an authorized 
source and sends a response message to the client computer without storing the document object 

on the server computer. 

Another aspect of the invem.on is a computer system for enabling a client computer to 
store a document object on a server computer. The server computer includes a computer- 
0 readable and writable storage medium and a server program executed by the server computer. 
The serx'er program, as executed, has an input for receiving a request message from the client 
computer, wherein the request message has content including a copy of the documem object, an 
indication of an application sending the message, an indication of a location on the server 
computer, and an indication that the document object is to be stored in the location on the sers'er 
25 computer. The server program as executed also includes a comparator having a first input for 
receiving the indication of the application and a second input for receiving an indication of an 
authorized source and an output providing an indication of whether the request message is from 
an authonzed source. The server program has a first output which provides a command to the 
server computer when the request message is from an authonzed source to store the document 
30 object on the computer readable and writable storage medium as a file using the name indicated 
in the request message. The server program also has a second output which.provides a response 
message to the client computer acknowledging storage of the document object when the request 
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message is from an authorized source and. when the request message is not from an authorized 
source, which provides a response message to the chent computer not acknowledging storage of 
the document object. 

Another aspect of the invention is a computer-implemented process for enabling a client 

5 computer to edit a document object stored on a server computer. In the process, a first HTTP 
request message is transmitted from the client computer over a TCP/IP connection to the server 
computer, wherein the first HTTP request message specifies the document object and an 
indication that the client computer requests retrieval of the document object from the server 
computer. A process is executed on the server computer using the first HTTP request message 

10 which retrieves a copy of the document object. The copy of the document object is transmitted 
from the server computer to the client computer over a TCP/IP connection in a first HTTP 
response message. The document object is then edited on the client computer. A second HTTP 
request message is transmitted from the client computer over a TCP/IP connection to the server 
computer, wherein the second HTTP request message contains a copy of the document object 

15 and an indication of a location on the server computer to store the copy of the document object 
and an indication that the client computer requests storage of the document object. A process is 
executed on the server computer using the second HTTP request message which stores the copy 
of the document object on the server computer according to the indication of the location 
included in the second HTTP request message. 

20 Another aspect of the invention is a computer system for editing of document objects, 

comprising a server computer and a client computer. The client computer includes a mechanism 
for sending a first HTTP request message over a TCP/IP connection to the server computer, 
wherein the first HTTP request message specifies the document object and an indication that the 
client computer requests retrieval of the document object from the server computer. The client 

25 computer also includes a mechanism for receiving an HTTP response message from the server 
including the copy of the requested document object and a mechanism for editing the document 
object on the client computer. The client computer also includes a mechanism for sending a 
second HTTP request message over a TCP/IP connection to the server computer, wherein the 
second HTTP request message contains a copy of the edited document object and an indication 

30 of a location on the server computer to store the copy of the document object and an indication 
that the client computer requests storage of the document object. The server computer includes 
a mechanism for executing a process on the server computer using the first HTTP request 
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message which retrieves a copy of the document object. The server computer also includes a 
mechanism for transmitting the copy of the documem object from the server computer to the 
client computer over a TCP/IP connection in the HTTP response message. The server computer 
also includes a mechanism for executing a process on the server computer using the second 
HTTP request message which stores the copy of the documem object on the server computer 
according to the indication of the location included in the second HTTP request message. 

Another aspect of the present invemion is a computer-implemented process for enabling a 
cliem computer to edit a document object on a serx'er computer. The process involves sending a 
read request message from the client computer to the server computer, wherein the read request 
message specifies the document object using an indication of a location on the server, defining 
an indicated name which is a universal name used by other clients to retrieve the document 
object, and an indication that the client computer requests retrieval of the documem object. On 
the server computer, the indication of the document object is converted to a file name in a file 
name space of the ser^'e^ computer and retrieving a copy of the document object from the server 
computer using the file name. The copy of the documem object is sent from the server computer 
to the client computer in a read response message. The copy of the document object is then 
edited on the cliem computer. A write request message is sem from the client compmer to the 
server computer, wherein the write request message includes a copy of the document object, a 
universal name for the documem object to be used by other cliems to access the document object. 
} and an indication that the documem object is to be stored on the server computer to be accessible 
by the cliem computer using the universal name in the message. On the server computer the 
indicated name is converted into a file name in the file name space of the server computer and 
storing the documem object as a file using the file name in the file name space. A write response 
message is sent to the cliem computer acknowledging storage of the document object. 
5 Another aspect of the invention is a client application for use on a client computer for 

editing a document object stored on a remote server computer. The client application has an 
imegrated user interface providing access to simultaneously to three mechanisms. The first 
mechanism retrieves the document object from the server computer. The first mechanism sends 
a read request message to the server computer including an indication of the document object 
30 using a universal name to be used by other clients to access the document object, and an 

indication that a copy of the document object is to be sent by the server computer to the client 
computer, then receives a read response message from the ser%'cr computer including the copy of 
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the document object, and then stores the copy of the document object in memory. The second 
mechanism is for editing the document object stored in the memory. The third mechanism is for 
storing the edited document object on the server computer. The third mechanism sends a write 
request message to the server including the copy of the edited document object from the buffer 
5 and an indication of a universal name to be used by other clients to access the document object 
on the server to store the edited document object, then receives an acknowledgment message 
from the server computer and for communicating the acknowledgment message to a user, and 
finally allows a user to activate any of the means for retrieving, editing or storing with an 
integrated user interface. 

10 Another aspect of the invention is a computer-implemented process for enabling a client 

computer to edit a document object on a ser\'er computer. This process involves transmitting a 
read request message from the client computer to the sender computer, wherein the request 
message includes an indication of the document object, an indication of an application sending 
the message, and an indication that the document object is to be sent to the client computer. It is 

15 then determined, on the server computer, whether the read request message is from an authorized 
source by comparing the indication of the application in the content of the request message with 
accepted applications. When the read request message is from an authorized source, a copy of 
the document object is retrieved on the server computer and a first response message is sent to 
the client computer including the copy of the document object. When the read request message 

20 is not from an authorized source, a response message is sent to the client computer without 
sending a copy of the document object. The copy of the document object is then edited on the 
client computer. A v^ite request message is transmitted from the client computer to the server 
computer, wherein the write request message includes a copy of the document object edited by 
the client computer, an indication of a location on the server computer, an indication of an 

25 application sending the message, and an indication that the document object is to be stored in the 
location on the server computer. It is then determined, on the server computer, whether the write 
request message is from an authorized source by comparing the indication of the application in 
the content of the request message with accepted applications. When the write request message 
is from an authorized source, the document object is stored on the server computer as a file using 

30 the location indicated in the write request message and sending an acceptance response message 
acknowledging storage of the document object. When the write request message is not from an 
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authorized source, a denial response message is sent to the chent computer without storing the 
document object on the server computer. 

It should be understood that other embodiments of the invention may be derived by those 
of ordinary skill in this art from the exemplary embodiment described below. Other aspects of 
the invention include the various combinations of one or more other aspects and particular 
embodiments of the invention, and the embodiments of these aspects of the invention as client 
systems. ser\'er systems and a combination of client and server systems. 

One advantage of this system is that current Web browsers do not need to be changed 
after installation of a control script at the Web server lo permit use of an authoring tool in 
accordance with this invention. This benefit is obtained in one embodiment by utilizing an 
HTTP method not used by the Web browser, the PUT method, to handle requests from the 
authoring tool. With this embodiment, changes to authoring tool systems can be made 
transparently to users who merely view information or use an on-line service. 

One advantage of this system over the prior an approaches is that the on-line service 
author can use a single client program and interface lo retrieve a script or document from an 
existing on-line ser\ ice on a server, edit or create a script or document for an on-line service, and 
save the resulting script or document to the appropriate place within the on-line service area on 
the server. 

Another advantage of this system is that the author of the on-line service can edit the on- 
line service documents and scripts from any client machine, so long as the client machine can run 
a Web browser and communicate via HTTP protocol with the Web server that hosts the on-line 
service. The client machine and server machine may have different types of processors, with 
different architectures, running different operating systems, in a heterogenous network. 

Another advantage of this system is that the authoring topi program communicates with 
the Web server program using the same type of network connection and the same protocol 
(HTTP) that is used by a Web browser talking lo a Web server. This means that the remote 
editing facility of the invention will work from any client that can support a Web browser 
communicating with an on-line service, li also means that remote editing with this invention 
does not require any additional network connectivity programs other than those needed for a 
Web browser to communicate with a Web server. 

Another advantage of this system is that the authoring tool uses the basic authentication 
procedures provided by the HTTP protocol and the Web server software. Access to files on the 
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server machine may be limited to service authors with a validated user name and password. 
Thus, by using the HTTP protocol that is already used for on-line services on the World Wide 
Web. a minimal level of security is provided during the authoring process. 

Another advantage of this system is that the authoring process can be used for remote 
5 retrieval, editing, and storing of at least two of the types of document objects that comprise an 
on-line service on the WWW: static HTML documents and script programs that generate HTML 
documents. 

Remote editing of on-line service document objects using the method of this invention 
also has several advantages over the prior art approaches, such as remote editing over a network 

10 file system where a client machine can read and write files on a remote server machine. One 

advantace is that our invention allows access to the online service document objects only through 
the Web ser\'er program, and thus conforms to the additional security rules implemented by the 
server program. A second advantage is that since our invention uses the existing HTTP protocol 
mechanism of the Web server machine, the ser\'er machine does not have to run additional 

15 software or server programs that are required to implement a network file system or shared 

access to a remote file system from a client machine. This is an advantage because the additional 
software would add complexity and would add further possibilities for security loopholes. A 
third advantage is that our invention allows access to the online service document objects only 
through the Web server program, and thus conforms to the document object name mapping 

20 conventions between URLs and actual file names of the Web ser\'er program. The advantage of 
the method of our invention is that neither client programs nor service authors need to understand 
this file name mapping and only need to use the URLs. 

Brief Descrintion of the Drawine 

25 In the drawing. 

Figure 1 shows the prior art sequence of activities on the Web browser during operation 
of an on-line service on the Web: 

Figure 2 shows the prior art sequence of activities on the Web server during operation of 
an on-line service on the Web: 
30 Figure 3 shows an overview of the authoring framework for remote authoring of on-line 

services: 
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Figure 4 shows the sequence of steps on the Web browser during remote authoring of an 
on-line service: 

Figure 5 shows the sequence of steps on the Web server during remote authoring of an 
on-line service: and 

Figures 6a and 6b show the messages that the client authoring tool sends to the server. 
Detailed Dgscrintion 

The following detailed description of an illustrative embodiment of the invention is made 
by way of example only. It should be read in conjunction with the drawing, in which similar 
reference numbers indicate similar structures. 

Figure 3 shows an overview of a computer system for remote authoring of on-line 
services. The system includes a client machine 80 connected to a serx'er machine 84 over a 
communication channel through which the client sends requests 108 and receives responses 1 10. 
The client machine has an authoring tool 82 which makes the requests 108. The ser^'er machine 
84 has a server program 86 which sends responses 110 to the authoring tool 82. The ser^'er 
program 86 has an associated control scnpt 88 which processes requests 108 and generates the 
responses 1 10 to be returned by the server program 86. The control script 88. in response to 
some requests 108. may be used to access on-line services 90 and 100. These ser^'ices may be 
authored using the authoring tool 82 to generate appropriate documents 92 and 102 and programs 
94 and 104. Generally speaking, the operating system of the client has a file name space which 
does not include or map to names of files on the server. 

In one embodiment of the invention the client machine 80 is a PC with an Intel 80486 
processor with a clock speed of 50 MHz. running the Microsoft Windows 3.1 operating system. 
The authoring tool 82 may be any of a variety of document editors, such as HTML editors, text 
editors, scnpt editors and the like. The exact form of the authoring tool and the functionality of 
the editor are up to the needs and desires of the user. However, such an authoring tool allows the 
retrieval and storage of a documem object on the Web ser^-er by generating an HTTP request 
message as described herein. Existing Web browsers could be modified to provide a storage 
function and editing capabilities to provide this functionality. Additionally. HTML and other 
0 editing tools may also be used in coiijunction with this invention if modified to allow for 

retrieving and storing f.les on the server by generating appropriate HTTP messages as described 
below. A larce number of HTML editors..such as HoTMetaL. from SoftQuad. Inc.. of Toronto. 
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Ontario. Canada, and other document editors and program editors, such as VisualBasic. may be 
used to create documents and scripts and the invention is not limited thereby. For example, the 
client machine 80 may have dial-up connection to an Internet service provider, typically using a 
14.400 baud or faster modem, and using the Trumpet 2.0b application for Microsoft Windows 
that provides the TCP/IP protocol software running over a SLIP connection using a normal 
telephone line. In this arrangement, the client machine 80 is connected to the Internet and has its 
own Internet address. 

In this embodiment, the server machine 84 is a Gateway 2000 personal computer with an 
Intel Pentium processor with a clock speed of 60 MHz. running the BSDi Unix operating system. 
The Web server program 86 is the CERN Hypenext Transfer Protocol Daemon (HTTPD) ser\'er. 
configured for the Unix operating system. The server machine 84 also has a dial-up connection 
to an Internet ser\'ice provider, using a 14,400 baud or faster modem, and using the TCP/IP and 
SLIP software that comes with the BSDi Unix operating system. Generally speaking, the Web 
server program is the only program providing access to documents, other than the operating 
system. It may define groups of users, user names, passwords and file names separately from the 
operating system of the server machine 84. With this configuration the client and server 
machines can establish a TCP/IP connection and exchange messages over the internet. It should 
be understood that this embodiment is merely exemplary. A large variety of computers and 
operating systems have suitable server and client software for communicating using HTTP over 
the Internet. The client and ser\'er machines may also be connected by a local area network 
(LAN), wide area network (WAN) or may even be the same machine, but with different 
processes communicating together over a common communication channel. Although 
communication is generally provided over a TCP/IP connection, other network communication 
protocols, including other data transport protocols and message protocols may be used. A 
variety of message protocols for communicating over TCP/IP connections may be used, such as 
HTTP, FTP. telnet, etc. However, generally speaking, the server and the client do not share fiies 
through the file name spaces of their respective operating systems. That is, the file name space 
of the client does not include or map to names of files on the server. In other words, no pair of 
file names in the two file names spaces correspond to the same file. More details about setting 
up client and server machines connected to the Internet and the World Wide Web are discussed 
in "Setting up Shop on the Internet." by Jeff Frentzen et al.. and related articles in WjpcjQws 
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Sources . Februan' 1995. pp. 42. 64-67. 70. 73-74. 77-80,106. 108. 1 1 1. 1 13-1 14, 1 17-120. 122. 

125. 128. 134-136. 13 8-140 and 143. 

Communication between the client authoring tool program on the client machine and the 
Web ser^'er program on the server machine can occur when both machines are connected to their 
respective Internet service providers. Communication between the server machine and client 
machine takes the form of the client sending an HTTP request to the server 108. the server 
processing the request, followed by the server replying with an HTTP response message to the 
cliem 1 10. In order to accomplish this, the client authoring tool program establishes a TCP/IP 
connection to the ser^'er program and sends the HTTP request message over that connection. 
The ser%-er program receives the HTTP request message, performs the indicated processing, and 
replies with an HTTP response message over the same connection. Finally the two programs 
terminate the TCP/IP connection. 

In this embodiment, when an HTTP PUT request is received by the sen-er program, the 
server program executes a control script 88 written in the Tel programming language. A suitable 
control script is described in more detail below in comiection with Figure 5 and is also found in 
the attached appendix. The attached appendix contains material which is subject to copyright 
protection. The copyright owner has no objection to the facsimile reproduction by anyone of the 
patent document or the patent disclosure containing this appendix, as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all rights whatsoever. 

It should be understood that the ser%'er program could just as well be programmed to 
respond to a POST request, given the current version of the HTTP standard. Other protocols, 
such as FTP could also be used. Different protocols and different messages could be used for 
both retrieval and storage. For example. FTP could be used to retrieve and HTTP could be used 
to store, or vice versa. Generally speaking, in this embodiment of the invention, the same type of 
i message is used to process both retrieval and storage of both documents and scripts. The 

particular message type is not limiting of this invention. For example, a Web server may allow a 
user to define custom message types. The control script program handles requests to retrieve or 
store objects in the service data areas 90 and 100 on the serv-er machine. There are two types of 
objects stored in each service data area: static documents in the HTML language 92 and 102. and 
0 script programs that generate HTML documents 94 and 104. 

Figure 4 shows a typical flow of control during one remote authoring session, where the 
service author uses the client machine to retrieve a document from the Web server, edit that 
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document on the client machine, and save the document back to the Web ser\'er. Figure 4 does 
not anempt to show editing, error handling, and graphical user interface features that are well 
Icnown in the prior art for text editors and word processing programs. For instance it does not 
show that the user may be editing several documents independently within several windows, or 
5 that the user may abort an editing session at any time without saving a document, or that the user 
may retrieve, edit, save in one window and then repeat those steps for a different document in the 
same window. Furthermore, Figure 4 does not attempt to show the editing commands that the 
user uses to make changes to the document on the client machine because these are well known 
in the art. 

10 As shown in Figure 4. the service author first runs the authoring tool program on the 

client machine in step 120. which provides a graphical user interface for remote editing. The 
author then asks in step 121 lo edit a document or script from a panicular on-line service, and 
identifies the object by specifying a document or script name, the service name, and the address 
of the Web server where the service is stored, such as by using its URL. 

IS The authoring tool program then sends in step 122 an HTTP PUT request to the Web 

server where the service is stored. The structure of this PUT request is shown in Figure 6a which 
is described in more detail below, and includes header fields for authorization, the MIME version 
number, the request content type, and the content length in bytes. The body of the request 
includes a method command field that identifies the request as a retrieve request and a URL 

20 command field that gives the URL for the document or script object to be retrieved. 

When the Web server program receives an HTTP PUT request in step 124, it passes it lo 
the control script 88. The control script examines the parameters of the retrieve request, and 
writes an output file in step 126 that contains either the requested document or script, or an error 
message for the service author indicating why the request could not be satisfied. Generally 

25 speaking, the Web server program translates the URL into a file name in the file name space used 
by the operating system of the server machine. Such mappings are usually found in a 
configuration file for the server. The control script can also be made lo perform such translation 
and maintain its own configuration file of mappings. This can be done so that the server does not 
have to be reinitialized when mappings change, for example, by the creation of a new service. 

30 The detailed operation of the control script is shown in Figure 5. and is explained further below. 
When the control script has finished execution, the Web server sends the resulting output file to 
the client authoring tool via an HTTP response in step 128. 
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The authoring tool then receives the HTTP response, containing the document or script 
that the author requested, and the authoring tool displays the document or script in a new window 
in step 130. using an appropriate editor. If the response contains an error message for the 
service author then it is handled in the normal way that an editor program handles the case when 
a requested file cannot be found. In step 132 the service author edits the retrieved document 
using the appropriate editor. At any point during the editing process, the service author may 
issue a command to save the current version of the document or script being edited, as noted in 
step 134. The save command causes the authoring tool client program to send a replace request 
to the server. 

The replacement process is similar to the retrieval process described earlier. The 
authoring tool program sends an HTTP PUT request to the Web ser^'er where the service is 
stored 136. The structure of this PUT request is shown in Figure 6b. and includes header fields 
for authorization, the MIME version number, the request content type, and the content length in 
bytes. The body of the request mcludes a method command field that idemifies the request as a 
replace request, a URL command field giving the URL where the document or script is to be 
stored, and the contents of the script or document that is lo be saved on the server. 

As with the retrieve request, when the Web server program receives an HTTP PUT 
request, the server program in step 138 passes it to the control script 88. The comrol script 
examines the parameters of the replace request, and attempts to store the document or script on 
) the server at the location given by the URL {step 140). and v^Tites an output file that either 

contains a status message indicating that the request was completed, or contains an error message 
for the service author indicating why the request could not be satisfied (step 142). The detailed 
operation of the control script is shown in Figure 5. and is explained further below. When the 
control script has finished execution, the Web server sends the resulting output file to the client 
5 authoring tool via an HTTP response in step 1 44. 

When the authoring tool receives the HTTP response, if the response is an error message 
then the error message is displayed for the ser^'ice author in step 146. Otherwise the authoring 
tool informs the user that the document or script was successfully saved on the Web server 
machine in step 146. in either event, the authoring tool waits for a new command from the 
50 service author. 

Figures 6a and 6b show the structure of the HTTP request messages- that the authoring 
tool sends to the Web server. In each case the parameter "length" on the "Content-length" line is 
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replaced by the number of characters in the content pan of the message (the part of the message 
that follows the Content-length line). The HTTP requests include a single request line, followed 
by header fields in the HTTP header, followed by a blank line, followed by command fields in 
the HTTP request body, followed by optional data in the HTTP request body. Header fields have 
a header field name followed by colon (":") and a header field value. Command fields have a 
command field name followed by a colon (":") and a command field value. The format of the 
request line and header fields is defined by the HTTP protocol specification, while the format of 
the HTTP request body, including the command fields, is defined by the method of our 
invention. 

Figure 6a shows the HTTP request message format for a 'Vetrieve" request- The first line 

201 is the request line, comprising the "PUT" method name 211. followed by the URL for the 
object to be retrieved 221. followed by the HTTP protocol version number 231. The second line 

202 is the authorization header field, comprising the header field name 212. e.g.. 
"Authorization." followed by the header field value 222. in this case "Basic 
dmVybWVlcjpEb250Rm9yZ2V0VGhpcw==." This authorization field may be used to carT>' 
passwords for protection purposes by the Web server. For example, the Web server may only 
allow use of the PUT request message by particular users. Also, the Web server could look to 
the password when a user attempts to write to a file using the Web server. These and other 
securitv devices may be used in connection with this invention. The third line 203 is the MIME 
version header field, comprising the header field name 213. e.g.. "MIME__version." followed by 
the header field value 223. e.g.. " 1 .0". The fourth line 204 is the content type header field, 
comprising the header field name 214. e.g., "Content-type," followed by the header field value 
224. e.g., "applicationyx-vermeer." The fifth line 205 is the content length header field, 
comprising the header field name 215, e.g., "Content-length." followed by the header field value 
225 giving the length in bytes of the HTTP request body. The sixth line 206 is the blank line that 
separates the header fields from the HTTP request body. The seventh line 207 is the method 
command field, comprising the command field name 217. e.g., "method." followed by the 
command field value 227, "retrieve." The eighth line 208 is the URL command field, 
comprising the command field name 218, "uri." followed by the command field value 228 giving 
the URL for the object on the ser\'er machine that is to be retrieved. 

Figure 6b shows the HTTP request message format for a "replace" request. The first line 
301 is the request line, comprising the "PUT" method name 3U. followed by the URL 321 
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giving the location on the server where the document should be saved, followed by the HTTP 
protocol version number 331. The second line 302 is the authorization header field, comprising 
the header field name 312, e.g.. "Authorization." followed by the header field value 322, e.g.. 
"Basic dmVybWVlcjpEb250Rm9yZ2V0VGhpcw=." The third line 303 is the MIME version 
header field, comprising the header field name 313. e.g.. "MIME_version." followed by the 
header field value 323. e.g.. "1 .0". The fourth line 304 is the content type header field, 
comprising the header field name 314. e.g., "Content-type." followed by the header field value 
324. e.g.. "application/xvermeer." The fifth line 305 is the content length header field, 
comprising the header field name 315. e.g.. "Content-length." followed by the header field value 
325 giving the length in bytes of the HTTP request body. The sixth line 306 is the blank line that 
.separates the header fields from the HTTP request body. The seventh line 307 is the method 
command field, comprising the command field name 317. e.g.. "method." followed by the 
command field value 327. e.g.. "replace." The eighth line 308 is the content type command field, 
comprising the command field name 318. e.g., "Content-type," followed by the command field 
value giving the content type identifier 328. The ninth line 309 is the URL command field, 
comprising the command field name 319. e.g.. "url." followed by the command field value 329 
giving the URL for the object on the server machine that is to be replaced. 

The operation of the control script 88 as running on the server machine, will now be 
described in connection with Figure 5. As described above, in this embodiment the Web server 
program calls the control script when a retrieve or replace request arrives from the authoring tool. 
The control script processes the retrieve or replace request and WTites an output file that the Web 
server will send back to the client as the response to the retrieve or replace request. 

As shown in Figure 5. when the Web server calls the control script, the control script first 
reads the "Content-type" header field of the HTTP request header to get the document type in 
step 160. A test is performed to see if the document type given in the header field is 
"application/x-vermeer" (step 162). If the request is not from the authoring tool, then the control 
script writes an error message to the output file 164 and the control script terminates. When the 
document type indicates that the request is from the authoring tool, then the test performed in 
step 162 yields the answer. "Yes," and the control script reads the command fields from the body 
of the HTTP request (step 166). A test is then performed in step 168 in order to determine if the 
command fields are acceptable. This test involves determining whether: (1) there is a "method" 
command field (2) there is a "URL"command field, and (3) the command fields are syntactically 
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correci. If the command fields are not correct, then the control script writes an error message to 
the output file in step 170 and the control script terminates. If the command fields are 
acceptable, then the test in step 168 yields the answer "Yes" and the control script performs a test 
to determine if the "method" command field value indicates a retrieve request (step 172). If so. 
then another test is performed to determine if the file given in the "URL" command field value 
exists and is readable (step 174). If the result is "Yes" then the control script sets the content 
type by examining the file name extension in step 176. The control script then writes the HTTP 
response header containing the content type, and the data content of the indicated file, to the 
output file in step 178. and the control script terminates. If the test in step 174 yields the answer 
"No" then the control script v^ites an error message to the output file in step 180 and the control 
script terminates. 

If the "method" command field does not indicate a "retrieve request then the test in step 
172 yields the answer "No" and a test is performed to see if the command field indicates a 
"replace" request (step 182). If the "method" command field does not indicate a "replace" 
request then the test 182 yields the answer "No," the control script writes an error message to the 
output file in step 194. and the control script terminates. Otherwise, if the "method" command 
field indicates a "replace" request, then another test is performed in step 184 to determine if the 
file given in the "URL" command field value may be written by the authoring tool and this user. 
For example, the file may be written if the file does not currently exist, or if the file exists and 
the service author has authorization to write the file. Authorization may be determined by the 
Web ser\'er. to see if the user attempting to write to a file has provided a correct password. 
Authorization may also be determined by the underlying operating system, to see if the Web 
server has authorization to write to the file specified by the URL. If the result of the test in step 
184 is "Yes" then the control script stores the data of the HTTP request body in the file indicated 
by the "URL" command field value (step 186). The control script then sets the appropriate file 
permissions on the new file in step 188. writes the status message indicating the result of the 
command into the output file in step 190, and the control script terminates. If the file cannot be 
written then the test 184 yields the answer "No." the control script writes an error message to the 
output file in step 192. and the control script terminates. 

An advantage of this system is that the client authoring tool does not need to map the file 
name space of the server to its own file name space. This arrangement is particularly 
advantageous in large networks, such as the Internet, where there may be many authors of many 
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on-line services on many servers. In this environment, the ability to remotely author documents 
is made easier and eliminates the need for complex file systems like a network file system. 

Another advantage of this system is that the ability to store files on the server is made 
possible in a manner which is transparent to usage by any Web browser. By using a control, 
script to control processing of messages, the server also need not be modified. The server is 
simply configured to recognize the control script, thus allowing easy installation. 

Having now described an embodiment of the invention, it should be understood that the 
foregoing description is merely illustrative, having been presented by way of example only. 
Numerous other embodiments and modifications may be made. For example, the invemion is 
not limited to use on the Internet or using the Worid Wide Web or using the HTTP 
communication protocol. For example, the file transfer protocol (FTP) could also be used, using 
"get" and "put" commands in that protocol. Other protocols using messages communicated over 
TCP/IP connections are also possible. A mix of such protocols may also be used to perform 
retrieval or storage functions. It is also possible that a ser%'ice author will keep local copies of 
document objects of an on-line service so that only a remote storage function is used. 
Additionally, systems in which a client program modifies and stores documents and programs on 
the server using protocols over a TCP/IP connection between the client and the server are also 
within the scope of the invention. The cliem and server may be connected by the Internet, or a 
private local or wide area network or may be on the same machine. The client authoring tool 
may be configured to communicate only with the server. The processing of messages need not 
be provided by a control script added to the ser^'er. but may also be made possible by 
modifications to the server. These and other embodiments are considered to be within the scope 
and spirit of the present invention which is defined by the appended claims. 
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APPENPiy: 



# !/usr/local/bin/lclsh 



# file put_scripi 

# This is a put_script for a CERN server that supports the following 

# operations in the Vermeer authoring tool client: 
U retrieve - retrieve a document 

replace - replace a previously existing document 

(error if it didn't previously exist 
or if date/time is later than that passed in) 

- create a new document 
(error if it previously existed) 

- parse a basic document and return tcl 

- index a document 
(indexes should still be recreated regularly). 

- return a list of services on the server. 

- return a linkmap of documents on the server. 



H 
# 

n 
# 
# 
# 
# 
# 

U This script is triggered by an HTTP PUT method, but HTTP POST method 
# could also be used. 



create 

parse 
index 



listservices 
linkmap 



# proc DBG 'debug-string 
# 

#if debugging is enabled (/tmp/debug_put_script exists) then 

#write the debug-string to /tmp/put_script.dbg 

# 

proc DBG str { 
global dbgon 
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global df 



if! [info exists dbgon] { 

set dbgon [file exists /tmp/debug jui^scripi] 

ifSdbgon ! 

set df [open /tmp/put__scripi.dbg "w"] 



ifSdbgon { 

puts SdfSstr 



# 

# proc error -error-string' 

tf^ Generic error routine for getting a string back lo c 
U Note that this terminates the current process 

a 

proc error str ', 



DBG "error -'Sstr" 

puts stdout "Content-Type: text/html 
<html> 
<head> 

<title>Bad Request</title> 

</head> 

<body> 

<hl>Bad Request</hl> 

<hr> 

Sstr 
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</body> 
</html>" 



exit 0 

5 1 
# 

# proc mktempfile Tile' Tilename" 

10 # Create and open for writing a temporary file in STMPDIR 
# 

proc mktempfile ! File Filename } \ 
upvar 1 SFile file 
upvar 1 SFilename filename 
15 global tmpdir 

global tmpcount 
global env 



if. [info exists tmpdir] { 
20 if [info exists env(TMPDIR)] { 

set tmpdirSenv(TMPDIR) 
} else 1 

set tmpdir /tmp 

} . 

25 set tmpcount 0 

I 



# Need a way to ensure exclusive create... 

# (and maybe put a process id in here...) 
30 set filename StmpdirA^TtmpSunpcount 

incr tmpcount 

while {[file exists Sfilename] = 1 } { 



wo 96/29663 PCr/US96/0365fl 

-36- 

set filename $tmpdirAa"tinp$tmpcount 



incr tmpcount 

} 

set file (open Sfilename w] 



# 

# proc readline 'input line' 
10 # 

# Routine for reading a single line from stdin. 

# Reads no more than env{CONTENT_LENGTH) characters 

# (otherwise the process would hang waiting for nonexistent input) 

# Strips trailing CR. 

1 5 # returns - 1 if no more input. 
# 

proc readline Line { 
upvar SLine line 



20 global contentlength 
global env 



if ! [info exists contentlength] { 

if {[info exists env(CONTENT_LENGTH]} { 

set contentlength $env(CONTENT_LENGTH) 
} else { 

DBG "no CONTENT_LENGTH environment variable" 
set contentlength 0 

} 

DBG "contentlength - Scontentlength" 
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if {Scontentlength <=0) { 
return - 1 

/ 

if { [gets stdin line] <0; ! 
return - 1 

» 

# dont"i fully understand CRLF issues, but for now... 
incr contentlength [expr 0- ([sirins: length Sline] + 1 )] 
set line [string irimright Sline "\r"] 

DBG "input - Sline" 
return 0 

# 

# Execution starts here 
# 

if {[catch I 

DBG "in put_script" 

# 

U Make sure we have a document of type "application/x-vermeer" 
# 

if ![info exists env(CONTENT_TYPE)l { 

error "no content-typevnneed content-type: application/x-vermeer" 
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if {(string tolowerSenv(CONTENT_TYPE)l != "application/x-vermeer"] I 

error "bad content-type: $env(CONTENT_tYPE)\nneed content-type: application/ x-vermeer" 



5 # Read operation headers 

# Put them in the associative array 'headers', indexed by header name 

U 

while 1 [ 

if{[readlinc linel<0} ! 
10 #nomoreinpui 
break 

I 

I 



if {0==[string length Sline] } | 
1 5 # blank line, end of headers 

break 



set ws"\[ \W]*" 
20 set alpha '\(-A-Za-z\]" 

set searchexpr "$ws\($alpha+\)$ws:Sws\( .•\)" 
if [regexp Ssearchexpr Sline foo name value] [ 
set headers! [string tolower $name[) Svalue 
} else I 

-.5 error "bad header - \"$line\"" 



# 

30 # Compute 'pathroot' and molisaroof for future reference 
U 

if {[info exists env(PATH_TRANSLATED)]&&[info exists env(PATHJNFO)ll 1 
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sei ix [string last Senv(PATH_INFO) Senv(PATH_TRANSLATED)] 
set pathroot [string range Senv(PATH_TRANSLATED) 0 [expr $ix-l] ] 
] else { 

error "cannot determine root of document tree " 

\ 

set molisaroot [format "%s/Molisa" Spathroot] 
# 

U Most methods require a target url. 
U Gel and check it if it exists. 

u 

if (info exists headers! url)] { 
set url $headers(url) 
set fuUurl SpathrootSurl 
set urlextension [file extension Surl] 

if { 0 != [string first 7Molisa" Surl] J { 

error "document is not underneath /Molisa - Surl" 

» 

{ else { 
set url 
set fullurl 
set urlextension 

} 

# Get the method 
# 

if ![info exists headers! method)] { 
error "no method header" 
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set method $headers( method) 



DBG "method-Smethod 



# 

U Case off method 
# 

if ! 0 == [string compare Smethod linkmap] 1 ! 

set result [exec Smolisarool/intemal/getliks.tcl Smolisarootymtemal/geturl 

puts stdout "Content-Type: application/'x-vermeer-linkniap\n" 
puts stdout Sresult 
exit 0 

; elseif 1 0 == [string compare Smethod listservices] ! 1 

# these are the Molisa directoiies that arc_not_services 
set reserved 1 internal lib dummyputdir 1 
set rawlist (exec Is Smolisaroot] 



set services 
foreachfSrawlist ; 

if { [file isdirectory $molisaroot/$fl&<S: 
(-1 == [Isearch -exact Sreserved $f|) 1 1 
lappened ser\'ices $f 

» 

1 
I 

puts stdout Tontent-Type: vermeer/x-vermeer-servicelist\n 

30 foreach f Sservices { 
puts stdout Sf 
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puts stdout TNDOFLIST " 
exit 0 

} elseif {0 == f string compare Smethod index] } { 
# Index 

DBG "entered index " 



set indexer /usr/local/bin/waisindex 
if ![file exits Sfullurl] [ 

error "document does not exist - Surl" 

t 



if ![file exists Sindexer] { 

error "indexer does not exist - Sindexer" 

if ![file readable Sfullurl] { 

error "document not readable - Surl" 

* 

if [file isdirectory Sfullurl] [ 

DBG "directory index branch" 
set service [file tail Surl] 

# We use a Web directory for the html pages, and a parallel wais 

# directory, rather than mixing wais index files into the Web hierarchy 

set www [file dimame $pathroot]/wais/$service 

catch ! exec Sindexer - mem 2 -1 1 -export -d $www \ 

-t URL Smolisaroot/Sservice http://zorch.tiac.net/Molisa/$service \ 
-r Smolisaroot/Sservice) result 
DBG "result = -Sresult-" 
) else { 
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DBG Tile index branch" 

set below [string range Surl 8 end] 

set service [file dimame Sbelow] 

# We use a Web directory for the html pages, and a parallel wais 

# director)', rather than mixing wais index files into the Web hierarchy 

set www [filed dimame $pathroot]/wais/$service 
DBG "molisaroot/below = Smolisaroot/Sbelow" 
catch { exec Sindexer -mem 2 -1 1 -export -d $www v 

-t URL Smolisaroot/Sservice http://zorch.tiac.netyMolisa/Sse^^'ice \ 

-r Smolisaroot/SserviceJ result 
DBG "result = -Sresuli 



puts stdout " Content-Type: text/html 

<html> 
<head> 

<title>Indexing of $url</title> 

</head> 

<body> 

<hl>Indexing of Surl succeeded</hl> 
<pre> 

puts -nonewline stdout Sresult 
puts stdout" 

</pre> 
</body> 
</html>" 
exit 0 

} elseif { 0 = [string compare Smethod retrieve] } I 
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# Retrieve 

# 

if ! [file exists Sfullurl] { 

error "document does not exist - Surl" 

i 

if ! [file readable Sfullurl] { 

error "document not readalbe -Surl" 



if [ 0 ~ (string compare Surlextension .html] } [ 

set contenttype textyhtml 
I elseif { 0 = [string compare Surlextension .bas] i ! 

set contenttype text/x-basic 
) elseif { 0 == [string compare Surlextension .tci] J [ 

set contenttype text/x-tcl 

} else { 

set contenttype application/binary 

\ puts stdout "Content-Type: Sconienttype\n" 

set input [open Sfullurl rj 
while {[gets Sinput line] >=0} J 
puts stdout Sline 



5 



clost Sinput 



exit 0 

) elseif ((0 = [string compare Smethod replace]) || 
Q (0 == [suing compare Smethod create]) } J 

# 

U Replace or create 
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# 

# May already exist if we're replacing 

# Must not exists if we're creating 

if {0 == (string compare Smethod replace] 1 { 
U if ! [file exists Sfullurl] { 
U error "document does not exist - Surl" 

U ) 

^ ) 
! else 1 

if [file exists Sfullurl] ! 

error "document exists - Suri" 



if [catch Isct output [open Sfullurl w] }] { 
) error "document not writable - Surl" 

> 

# Assume text 
set text I 

0 if [info exists headers! content-type) ! 

set contentiype $headers( content-type) 
if ![regexp -nocase "^text/" Scontenttype] { 
set text 0 

\ 
I 

25 ) 

DBG "text = 'Stext'" 
if {Stext 1 I 

while • [readline line] >=0 ) ( 
puts Soutpul Sline 

30 1 
} else 1 

DBG "about to read 'Scontentlength' bytes" 
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exec >(3). Souiput $molisaroot/intemal/read Scontentlenglh 
close $output 

# Quick detection of executable files 

# If the directon' name is "Scripts" make it executable 

if {0 = [string compare Scripts [file tail [file dimame SfuUurl]]!} { 
exec chmod a+x SfuUurl 

> 

puts stdout "Content-Type: text/html 



<html> 
<head> 

1 5 <title>Create/replace succeeded</title> 
</head> 
<body> 

<hl>Create/replace succeeded </hl> 
</body> 
20 </html>" 



exitO 

} elseif {0 == [string compare Smethod parse] } { 

25 # Parse 
# 

mktempfile basicFile baseFileName 



while { [readline line] >=0 } { 
30 puts SbasicFile Sline 

close SbasicFile 
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mktempfile tclFile iclFileName 
close StclFile 



set 



fail [catch {execSmolisaroot/mtemal/parser<$basicFileName>$tcl^ result] 



if {SfaiU { 

puts stdout "Content-Type: text/html 

<html> 
<head> 

<title>Parse failed</litle> 

</hcad> 

<body> 

<hl>Parse failed</hl> 

<pre> 

Sresult 

</pre> 

</body> 

</html>" 

} else J 

puts stdout "Content-Type: text/html 

<html> 
<head> 

<title>Parse succecded</title> 

</head> 

<body> 

0 <hl>Parse succeeded</hl> 
<pre>" 
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set tclFile [open StclFileName "r"] 
while { [gets StclFile line] >=0} { 
puts stdout Sline 

\ 
J 

puts stdout "</pre> 

</body> 
</htmI>" 

i 

exec rm SbasicFileName StclFileName 

> 

} vfr_j3ut_result] } { 

DBG "put caught - •$vfr_put_result'" 
puts stdout "Content-Type: text/html 



<HEAD><TITLE>Put Error</TITLE></HEAD><BODY> 
<Hl>Put Error</Hl><pre>$vfr_j)ut_result</pre></body>" 
exit 0 
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CLAIMS 

1 A computer-implemented process for a diem to remotely edit a doctmiem object stored 
on a server, wherem the diem and the server communicate using an HTTP protocol over a 
connection, comprising the steps of: 

establishing a connection between the diem and the server. 

the diem sending an HTTP request message over the TCP/IP connection to the server, 
wherein the HTTP request message specifies the documem object and an indication that the 
client requests retrieval of the document object. 

the serN'er receiving the HTTP request message and calling a script. 

the script retrieving a copy of the documem object. 

the ser^'er sending the copy of the document object to the cliem over the TCPAP 
connection in an HTTP response message. 

the client receiving the HTTP response message including the copy of the documem 

object. 

the cliem permitting editing of the copy of the documem object, 
the cliem sending an HTTP request message to the server, wherein the HTTP request 
message contains a copy of the edited documem object and an indication of a location on the 
server to store the copy of the edited document object and an indication that the cliem requests 
storage of the edited document object. 

the server receiving the HTTP request message and calling the script, 
the scnpt stonng the copy of the edited document object on the server according to the 
indication of the location included in the HTTP request message, and 
terminating the connection. 



25 



: The process of claim 1 . funher comprising the step of the script checking authentication 
and wherein the step of the scnpt retrieving the copy of the documem object includes retrieving 
the copy only when access to the documem object is authemicated. 

3. The process of claim 1 . further comprising the step of mapping the indication of the 
30 location of the document object to a file name on the server. 

4. The process of claim 1. ftirther comprising the step of the server responding with an HTTP 
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response message to the client program, indicating one of acknowledgment that the document 
was successfully saved and giving an error indication. 

5. The process of claim 1. wherein the document object is part of an online service on the 
World Wide Web. 

6. The process of claim I . wherein the document object is comprised of an HTML file. 

7. The process of claim 1 , wherein the document object is a computer program written in a 
computer programming language. 

8. The process of claim 1 . wherein the script is a single computer program which processes 
both retrieve and store requests and is called by the server in response to either a store or a 
retrieve request from the client. 

9. The process of claim 1 . wherein the HTTP protocol includes a named message method 
which indicates transfer of arbitrary data from the client to the server and w»- .; ein the client 
sends the server a message including the name of the named message -. ..ethod for both retrieve 
and store requests. 

1 0. The process of claim 9. wherein the named message method is an HTTP "PUT" message. 

11. The process of claim 9, wherein the named message method is an HTTP "POST" 
message. 

1 2. The process of claim 1 . wherein the server and client are on the same computer. 

13. The process of claim 1 . wherein the server and the client are on separate computers 
interconnected by a network. 

0 

1 4. The process of claim 1 3 . wherein the network is a local area network. 
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ls. The process of claim 1 3, wherein the network is Internet. 

16. The method of cla.m l, wherein the server call, one of multiple scripts. 

,7. The method of claim 1. wherein the connection established is a TCP/IP connection. 

18. The method of claim 4, farther compnsmg the step of termmatmg the TCP/IP connection 
after the step of the server sending a response message. 

1 9. The process of claim 1. wherein the documem object is an HTML file including an 
embedded graphic image. 

,0 A compwcr-implememed process for remo.dy eduin. an elecuonic documem stored on a 
server compmer. usin. . clicn. computer, wherein .he server computer and the cliem computer 
are connected via a communication channel ustng a communication protocol, and wheretn the 
diem computer has an operattns system with a ftrs. fie name space and the server computer has 
an operating svstem w„h a second file name space and no file in the second file name space can 
be accessed using the name of a file in the firs, file name space, the process compristng the steps. 

performed by the client computer, of: 

sending a request message in the communication protocol and over the communicatton 

channel to the serx'er requesting a copy of the electronic document. 

receiving a response message in the communication protocol from the server and over the 
communication channel, wherein the response message contains the copy of the electron.c 

document. 

permitting edittng of the copy of ^ elecuonic document at the cUem computer, and 
sending a message in the communication protocol including the edited electron.c 
document over the communication channel and to the server, wherein the message includes an 
indication of a request .hat the electronic documem be stored on the server computer. 

30 . 1 A computer-implememed process for remo.ely ediiing an elecronic documem stored on 
server computer, using a client computer, whe«in the server computer and the cliem computer 
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are connected via a communication channel using a communication protocol, the process 
comprising the steps, performed by the client computer, of: 

sending a request message in the communication protocol and over the communication 
channel to the server requesting a copy of the electronic document using a name mappable to the 
file name space of the server and not mappable to the file name space of the client. 

receiving a response message in the communication protocol from the server and over the 
communication channel, wherein the response message contains the copy of the electronic 
document. 

permitting editing of the copy of the electronic document at the diem computer, and 
sending a message in the communication protocol including the edited electronic 
documem over the communication channel and to the server, wherein the message includes an 
indication of a request that the electronic document be stored on the server computer using a 
name mappable to the file name space of the server and not mappable to the file name space of 
the client. 

22. A client computer system for use in connection with a server computer connected to the 
client computer via a communication channel using a communication protocol, and wherein the 
client computer has an operating system with a first file name space and the server computer has 
an operating system with a second file name space and the first file name space does not include 
names of files which map to names of files in the second file name space, the client computer 

system comprising: 

means for sending a request message over the communication channel in the 
communication protocol to the server for a copy of the electronic document. 

means for receiving a response message in the communication protocol from the ser\'er 
and over the communication channel, wherein the response message contains the copy of the 

electronic document. 

means for permitting editing of the copy of the electronic document at the client 

computer, and 

means for sending a message in the communication protocol including the edited 
electronic document over the communication channel and to the server, wherein the message 
includes an indication of a request that the electronic document be stored on the ser\'er computer. 



PCT/US96/03650 

WO 96/29663 

-52- 

23 A seiner computer system for use in connection with a client computer connected to the 
server computer via a communication channel using a communication protocol, and whcr.m the 
client computer has an operating system with a first file name space and the server computer has 
an operating system w.th a second file name space and the first file name space does not mcMe 
names of files which map to names of files .n the second file name space, the server computer 
system comprising: 

means for receiving a request message over the communication channel m the 
communication protocol from the client for a copy of the electronic document, 
means for retrieving the copy of the electronic document. 

means for sending a response message m the commumcation protocol to the client and 



channel, wherein the response message contains the copy of the 
the communication protocol including an edited 



over the communication 
electronic document. 

means for receiving a message in 
elec»,>ic documem over the con,mu„.ca,ion chapel and from ,he cliem. wherein Ae messag. 
Includes an indicauon of a request that the electronie document be stored on the ser,.er computer 



e 



and 

means for storing the edited electronic document on the sender computer system. 

.4 A computer-implemented process for editing an electronic document and for use in 
, connection with a cliem computer connected to a server computer via a communication chamtel 
using a communication protocol, and wherein the cliem computer has an operating system with a 
first file name space and the server computer has an operating system with a second file name 
space and the first file name space does not include names of files which map to names of files in 
the second file name space, the process comprising the steps, performed by the server, of: 
5 receiving a request message over the communication chamtel in the communication 

protocol from the client for a copy of the electronic documem. 
retrievinc the copy of the electronic document. 

sending a response message in the communication protocol to the cliem and over the 
communication channel, wherein the response message contains the copy of the electromc 
30 document. 
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receiving a message in the conraiunication protocol including an edited electronic 
document over the communication channel and from the client, wherein the message includes an 
indication of a request that the electronic document be stored on the server computer, and 

storing the edited electronic document on the server computer system. 

5 

25. A computer-implemented process for remotely editing an electronic document stored on a 
server, wherein the client and the server communicate over a communication channel using a 
communication protocol, and wherein the client computer has an operating system with a first 
file name space and the server computer has an operating system with a second file name space 
10 and the first file name space does not include names of files which map to names of files in the 
second file name space, comprising the steps of: 

the client establishing the communication channel with the server, 
the client sending a message in the communication protocol over the communication 
channel to the sen'er. wherein the message specifies the electronic document and an indication 
1 5 that the client requests retrieval of the elecn-onic document. 

the server receiving the message and checking authentication, 
the server retrieving a copy of the electronic document if access is authenticated, 
the server sending the copy of the electronic document to the client over the 
communication channel in a message in the communication protocol, 
20 the client receiving the message from the server including the copy of the electronic 

document. 

the client permitting editing of the copy of the electronic document, 
the client sending a message over the communication channel and in the communication 
protocol to the server, wherein the message contains a copy of the edited document and an 
25 indication of a location on the ser\'er to store the copy of the edited document and an indication 
that the client requests storage of the edited document, 

the server receiving the message and storing the copy of the edited document on the 
server at the location specified in the message, and 

the server sending a message acknowledging an attempt at storage of the edited 
30 document. 



26. 



A computer system for remotely editing an electronic document, comprising: 
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a client computer and a server computer interconnected by a communication channel 
using a communication protocol, and wherein the client computer has an operating system with a 
first file name space and the server computer has an operating system with a second file name 
space and the first file name space does not mclude names of files which map to names of files m 

the second file name space, 

wherein the client computer includes: 

means for sending a request message over the communication channel in the 
communication protocol to the server for a copy of the electronic documem. 

means for receiving a response message in the communication protocol from the server 
and over the communication channel, wherein the response message contains the copy of the 

electronic document 

means for permitting editing of the copy of the electronic documem at the client 

computer, and 

means for sending a message in the communication protocol including the edited 
electronic document over the communication channel and to the server, wherein the message 
includes an indication of a request that the electmnic documem be stored on the serx'er computer, 
and 

wherein the server computer includes: 

means for receiving a request message over the communication channel in the 
communication protocol from the client for a copy of the electronic document, 
means for retrieving the copy of the electronic documem. 

means for sending a response message in the communication protocol to the cliem and 
over the communication channel, wherein the response message contains the copy of the 
electronic document. 

1 means for receiving a message in the communication protocol including an edited 

electronic documem over the communication chamiel and from the cliem. wherein the message 
includes an indication of a request that the electronic documem be stored on the server computer, 
and, 

for storing the edited electronic documem on the server computer system. 



means 

0 



27. A process for handling a request message from a remote editor, comprising the steps of: 
determining whether the request message is from a cliem authoring tool. 
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determining whether the request message is for retrieval of a document object when the 
request message is from the authoring tool, 

sending a response message to the authoring tool including the document object when the 
request message is for retrieval 

determining whether the request message is for storage of a document object when the 
request message is from the authoring tool. 

storing the document object when the request message is for storage, and 

sending a response message to the authoring tool acknowledging storage of the document 

object when the request message is for storage. 

28. A process for saving a document object on a remote server, and wherein the client 
computer has an operating system with a first file name space and the server computer has an 
operating system with a second file name space and the first file name space does not include 
names of files which map to names of files in the second file name space, comprising the steps 
of: 

sending a request message to the remote server, wherein the request message includes the 
document object, an indication of a location on the remote server and an indication that the 
document object is to be stored on the remote server. 

the remote server receiving the request message and converting the indication of the 
location into a file name, and storing the document object as a file using the file name, and 

the remote server sending a response message acknowledging storage of the document 

object. 

29. A client computer for use in a client/server computer system for remotely editing 
document objects stored on the server computer, the client computer comprising: 

an editing system having inputs connected to receive editing commands, a memory for 
storing the document object while it is edited in response to the editing commands and an 
outputfor displaying the document object to the user during editing, 

a retrieve request message processor having an input connected to receive an indication 
of a document object on the server to be retrieved and an output providing a retrieve request 
message, including an indication of the document object, to a communication channel connected 
to the server computer: 
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a response message processor having an input connected to receive a response message 
from the server and operative when the retrieve request message section sends a retrieve request 
message to the server, wherein the response message includes the document object, and an output 
providing the document object to the memorj' of the editing system, and 

a store request message processor, connected to access the memory of the editing system, 
and having an input connected to receive an indication of the location on the server for storing 
the document object and an output providing a store request message including the edited 
document object and an indication of a location on the server where the documem object is to be 
stored, wherein the output connects to the communication channel connected to the server. 

30. A server computer for use in a client/server computer system in which a client computer 
remotely edits document objects stored on the server computer, the sers'er computer comprising: 
memory in which document objects are stored. 

a retrieve request message processor having an input connected to receive retrieve request 
messages from the client computer, wherem a retrieve request message includes an indication ot" 
a document object stored on the ser^■er. wherein the retrieve request message processor accesses 
the memory to retrieve the document object indicated in the retrieve request message, and having 
an output providing a response message including the retrieved document object to the client 
computer, and 

a store request message processor having an input connected to receive store request 
messages from the cliem computer, wherein a store request message includes a document object 
and an indication of a location on the server for storing the document object, and which stores 
the documem object in a location corresponding to the indication in the store request message. 

i 3 1 . A process for remotely, storing a documem from a cliem to a server, comprising the steps 
of: 

establishing a TCP/IP connection between the client and the server, 
the cliem sending a request message over the TCP/IP connection to the server, the request 
message including the document to be stored and an indication of a location on the server in 

0 which the document is to be stored. 

the server receiving the request message and storing the document in a location 
corresponding to the indication in the request message. 
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32. A computer-implemented process for enabling a client computer to store a document 
object on a server computer, comprising the steps, performed by the server computer, of: 

receivine an HTTP request message from the client computer over a TCP/IP connection, 
wherein the HTTP request message has content including a copy of the document object and an 
indication of a location on the server computer to store the copy of the document object and an 
indication that the client computer requests storage of the document object: and 

executing a process using the content of the HTTP request message to store the copy of 
the document object on the server computer according to the indication of the location included 
in the HTTP request message. 

33. In a computer system for enabling a client computer to store a document object on a 
server computer, the server computer comprising: 

means for receiving an HTTP request message from the client computer over a TCP/IP 
connection, wherein the HTTP request message has content including a copy of the document 
object and an indication of a location on the server computer to store the copy of the document 
object and an indication that the client computer requests storage of the document object; and 

means for executing a process using the content of the HTTP request message to store the 
copy of the document object on the server computer according to the indication of the location 
included in the HTTP request message. 

34. In a computer system for enabling a client computer to store a document object on a 
server computer, the server computer comprising: 

a computer-readable and writable storage medium; 

a TCP/IP mechanism, having an input for receiving a request from the client computer to 
establish a TCP/IP connection vnxh the client computer and which establishes the TCP/IP 
connection: and 

an HTTP server having an input for receiving an HTTP request message from the client 
computer over the TCP/IP connection via the TCP/IP mechanism, wherein the HTTP request 
message has content including a copy of the document object and an indication of name used by 
the HTTP server to retrieve the document object as stored on the storage medium and an 
indication that the client computer requests storage of the document object, and an output for 
storing the copy of the document object from the HTTP request message on the computer- 
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readable and writable storage medium as a file according to the name included in the HTTP 
request message. 

35. A computer-implemented process for enabling a client computer to store a documem 
object on a server computer, comprising the steps, performed by the client computer, of 
establishing a TCPAP connection with the server computer; 

sending an HTTP request message to the server computer over the TCPAP connection, 
wherein the HTTP request message has content including a copy of the document object and an 
indication of a location on the serv'er computer to store the copy of the document object and an 
indication that the client computer requests storage of the documem object: and 

receiving an HTTP response message from the server computer indicating a result of an 
attempt by the ser^'er computer to store the copy of the document object. 

36. A computer-implemented process for enabling a client computer to store a document 
object on a server computer, the process comprising the steps, performed by the server computer, 
of 

receiving a request message from the cliem computer, wherein the request message has 
content including a copy of the document object, an indication of a location on the server 
computer, defining an indicated name which is a universal name used by other clients to access 
the document object on the server computer, and an indication that the document object is to be 
stored in the indicated location on the server computer; 

converting the indicated name into a file name m a file name space of the server computer 
and storing the document object as a file on the server computer using the file name in the file 
name space of the server computer: and 

sending a response message to the client computer acknowledging storage of the 

document object. 

37. In a computer system for enabling a cliem computer to store a document object on a 
server computer, the server computer comprising: 
0 means for receiving a request message from the client computer, wherein the request 

message has content including a copy of the document object, an indication of a location on the 
server computer, defining an indicated name which a universal name to be used by other cliems 
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10 retrieve the document object, and an indication that the document object is to be stored in the 
indicated location on the server computer; 

means for converting the indicated name into a file name in a file name space of the 
server computer and storing the document object as a file on the ser%'er computer using the file 
name in the file name space of the server computer; and 

means for sending a response message to the client computer acknowledging storage of 

the document object. 

38. In a computer system for enabling a client computer to store a document object on a 
server computer, the server computer comprising: 

a computer-readable and writable storage medium: 

a server program executed on the server computer having: 

a. an input connected to receive a request message from the client computer, wherem 
the request message has content including a copy of the document object, an indication of a name 
to be used by the server program to retrieve the document object which is a universal name used 
by other clients to retrieve the document object, and an indication that the document object is to 
be stored on the computer-readable and writable storage medium; 

b. a first output for providing a file name in a file name space of the server computer 
converted from the indicated name in the received message and a command to the server 
computer to store the document object as a file on the computer-readable and N^Titable storage 
medium using the file name in the file name space of the server computer: and 

c. a second output connected to the client computer to provide a response message to 
the client computer acknowledging storage of the document object. 

39. A computer-implemented process for enabling a cl lent computer to store a document 
object on a server computer, comprising the steps, performed by the server computer, of; 

receiving a request message from the client computer, wherein the request message has 
content including a copy of the document object, an indication of an application sending the 
message, an indication of a location on the server computer, and an indication that the document 
object is to be stored in the location on the server computer: 

determining whether the request message is from an authorized source by comparing the 
indication of the application in the content of the request message with accepted applications: 
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when the request message is from an authorized source, storing the document object on 
the server computer using the location indicated in the request message and sending a response 
message to the chem computer acknowledging storage of the document object: and 

when the request message is not from an authorized source, sending a response message 
5 to the client computer without storing the document object on the server computer. 

40. In a computer system for enabling a client computer to store a document object on a 
server computer, the server computer comprising: 

means for receiving a request message from the client computer, wherein the request 
10 message has coment including a copy of the document object, an indication of an application 
sending the message, an indication of a location on the server computer, and an indication that 
the document object is to be stored in the location on the server computer: 

means for determining whether the request message is from an authorized source by 
comparing the indication of the application in the content of the request message with accepted 
1 5 applications: 

means, operative when the request message is from an authorized source, for storing the 
document object on the server computer using the location indicated in the request message and 
sending a response message to the client computer acknowledging storage of the document 

object; and 

20 means, operative when the request message is not from an authorized source, for sending 

a response message to the cliem computer without storing the documem object on the server 

computer. 

41 . In a computer system for enabling a client computer to store a documem object on a 
25 server computer, the server computer comprising: 

a computer-readable and writable storage medium: 

a seiner program executed by the server computer having: 

a. an input for receiving a request message from the cliem computer, wherein the 
request message has contem including a copy of the documem object, an indication of an 
30 application sending the message, an indication of a location on the server computer, and an 
indication that the document object is to be stored in the location on the server computer: 
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b. a comparator having a first inpui for receiving the indication of the application and 
a second input for receiving an indication of an authorized source and an output providing 
indication of whether the request message is from an authorized source; 

c. a first output which provides a command to the server computer when the request 
message is from an authorized source to store the document object on the computer readable and 
writable storage medium as a file using the name indicated in the request message; and 

d. a second output which provides a response message to the client computer 
acknowledging storage of the document object when the request message is fi-om an authorized 
source and, when the request message is not from an authorized source, which provides a 
response message to the client computer not acknowledging storage of the document object. 

42. A computer-implemented process for enabling a client computer to edit a document 
object stored on a ser\'er computer, comprising the steps of: 

transmitting a first HTTP request message from the client computer over a TCP/IP 
connection to the server computer, wherein the first HTTP request message specifies the 
document object and an indication that the client computer requests retrieval of the document 
object from the server computer: 

executing a process on the server computer using the first HTTP request message which 
retrieves a copy of the document object: 

transmitting the copy of the document object from the server computer to the client 
computer over a TCP/IP connection in a first HTTP response message: 

editing the document object on the client computer: 

transmitting a second HTTP request message from the client computer over a TCP/IP 
connection to the server computer, wherein the second HTTP request message contains a copy of 
the document object and an indication of a location on the server computer to store the copy ot 
the document object and an indication that the client computer requests storage of the document 
object: 

executing a process on the server computer using the second HTTP request message 
which stores the copy of the document object on the server computer according to the indication 
of the location included in the second HTTP request message. 



43. 



A computer system for editing of document objects, comprising: 



on on the 
the 



wo 96/29663 PCr/US96/0365« 

-62- 

a server computer and a client computer, 
wherein the client computer, comprises: 

means for sending a first HTTP request message over a TCP/IP connection 
to the server computer, wherein the first HTTP request message specifies the 
document object and an indication that the cliem computer requests retrieval of the 
document object from the server computer; 

means for receiving an HTTP response message from the ser^'e^ including 

the copy of the requested document object; 

means for editing the document object on the client computer: and 
means for sending a second HTIT request message over a TCP/IP 
connection to the server computer, wherein the second HTTP request message 
contains a copy of the edited document object and an indication of a location or 
serx'er computer to store the copy of the document object and an indication that 
client computer requests storage of the document object: and 
wherein the server computer comprises: 

means for e.xecuting a process on the server computer using the first HTTP 
request message which retrieves a copy of the document object: and 

means for transmitting the copy of the document object from the serN'er 
computer to the client computer over a TCP/IP connection in the HTTP response 
message: and 

means for executing a process on the server computer using the second 
HTTP request message which stores the copy of the document object on the server 
computer according to the indication of the location included in the second HTTP request 

message. 

44. A computer-implemented process for enabling a client computer to edit a document 
object on a serv'er computer, the process comprising the steps of: 

sending a read request message from the client computer to the ser%'er computer, wherein 
the read request message specifies the document object using an indication of a location on the 
server, defining an indicated name which is a universal name used by other clients to retrieve the 
document object, and an indication that the client computer requests retrieval of the document 
object: 
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Vf converting, on the server computer, the indication of the document object to a file name 
in a file name space of the server computer and retrieving a copy of the document object from the 
server computer using the file name; 

sending the copy of the document object from the server computer to the client computer 

in a read response message; 

editing the copy of the document object on the client computer: 

sending a write request message from the client computer to the server computer, wherein 
the wTite request message includes a copy of the document object, a universal name for the 
document object to be used by other clients to access the document object, and an indication that 
the document object is to be stored on the server computer to be accessible by the client 
computer using the universal name in the message; 

converting on the ser\'er computer the indicated name into a file name in the file name 
space of the ser\'er computer and storing the document object as a file using the file name in the 
file name space: and 

sending a write response message to the client computer acknowledging storage of the 
document object. 

45. A client application for use on a client computer for editing a document object stored on a 
remote ser\'er computer, comprising, with an integrated user interface providing access to 
simultaneously to: 

a. means for retrieving the document object from the server computer, including 

i) means for sending a read request message to the server computer including 
an indication of the document object using a universal name to be used by other 
clients to access the document object, and an indication that a copy of the document 
object is to be sent by the server computer to the client computer. 

ii) means for receiving a read response message from the server computer 
including the copy of the document object, and 

iii) storing the copy of the document object in memory. 

b. means for editing the document object stored in the memory; 

c. means for storing the edited document object on the server computer, 
including 
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i ) means for sending a write request message to the server including the copy 
of the edited document object from the buffer and an indication of a universal name to 
be used by other clients to access the document object on the server to store the edited 

document object, and 

iil means for receiving an acknowledgment message from the server 
computer and for communicating the acknowledgment message to a user, and 
d. means allowing a user to activate any of the means for retrieving, editing or 
storing with an integrated user interface. 

46. A computer-implemented process for enabling a client computer to edit a document object 
on a server computer, comprising the steps of: 

transmitting a read request message from the client computer to the server computer, 
wherein the request message includes an indication of the document object, an indication of an 
application sending the message, and an indication that the document object is to be sent to the 
client computer: 

determining on the server computer whether the read request message is from an authorized 
source by comparing the indication of the application in the content of the request message with 

accepted applications: 

when the read request message is from an authorized source, retrieving a copy of the 
0 document object on the server computer and sending a first response message to the client 
computer including the copy of the document object: and 

when the read request message is not from an authorized source, sending a response 
message to the client computer without sending a copy of the document object: 
editing the copy of the document object on the client computer: 
5 transmitting a write request message from the client computer to the server computer, 

wherein the write request message includes a copy of the document object edited by the client 
computer, an indication of a location on the server computer, an indication of an application 
sending the message, and an indication that the document object is to be stored in the location on 
the server computer; 

30 determining, on the sen'er computer, whether the write request message is from an 

authorized source by comparing the indication of the application in the content of the request 
message with accepted applications: 
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when the write request message is from an authorized source, storing the document object 
on the server computer as a file using the location indicated in the write request message and 
sending an acceptance response message acknowledging storage of the document object: and 

when the write request message is not from an authorized source, sending a denial response 
5 message to the client computer without storing the document object on the server computer. 
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